Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/ucp/ucp-minutes-91mar.txt

Text File | 1993-02-17 | 7.5 KB | 316 lines

CURRENT_MEETING_REPORT_



Reported by Dan Long/BBN and Karen Roubicek/BBN

UCP Minutes

Summary

The UCP meeting consisted of a discussion of the UCP Internet Draft.
Some of the discussion was to clarify aspects of the draft.  The main
issue that arose is the obligation for an NSC to accept calls from
anyone on any subject.  It was agreed that an NSC should be allowed to
limit its ``liability'' by referring callers from outside its customer
base or specialty to the ``right'' NSC. The draft will be ammended to
reflect that.

There was also discussion on the issue of the centralized aspects of the
UCP plan--how much monitoring is done by the Ticket Support Center and
which tickets get tracked by the Ticket Tracking System.  There was no
consensus on the details but people felt that not all tickets should be
tracked and that perhaps suggesting NSC's produce reports on ticket
activity would be the most we could ``standardize''.

There was a brief discussion on the format/mechanism for ticket handoffs
but it was acknowledged that we really need some operational experience
before suggesting any specifics.

Issues

   o Complaints that are dropped between NOC's.
   o NOCs that lose tickets.
   o Status of problems in design and engineering of networks.
   o Statistics on complaints for evaluation.
   o Accountability.


Cases

   o End host is down.
   o MILNET.
   o General international connections.
   o Anomalous or unexpected routing through experimental networks.
   o Telnet options negotiations.
   o Vendor software problems.
   o General host or applications problems.

                                   1






   o Limitations of low-budget implementations.
   o Packet filters.
   o Lack of complete problem description.
   o Kludge requests.


END HOST IS DOWN - example:  user called NEARNET to report that unable
to get to andrew.cmu.edu
Two models

1.  Nearnet follows through:


user----> |nearnet|-----> cmu
    <---  |  nsc  |<----



2.  Pass off to CMU nsc:


user---->nsc---cmu <---> cmu
 |        nsc
 |              |
 \______________/



It's rare that a campus would be an NSC because they don't want to
track/handle problems outside their campus.



     (user services) user -----> campus-----> nearnet nsc



NSC is required to:


   o Take ticket regardless of class of problem.
   o **agrees to abide by a core set of rules**.
   o Implies responsibility for accepting calls and passing tickets.


Organization can have something outside of its organization that can

                                   2






break rules (like saying ``you're not my customer'')

not accept calls  <----->  wrong number concern there will be an
overload of calls - e.g.:  MERIT

Dana Sitzler:  why would a NOC want to be an NSC? What's at the root of
the problem?  help users, ``support'' funding agencies

Issue of coercion:  If I have to take calls, it becomes a funding issue

Suggest limits on what calls NSC has to take:


   o Who must I take calls from?
   o What kind of a call must an NSC accept?


       ________________
NSC customers: peers          |       |       |
       nsc's          | help  | NSC   |
      |_______|_______|

Help - acts as filter - redirects people to other NSC's



Question of hours or operation:  not specified, too variable among
organizations
Store information about NSC's in DNS? (eventually) Start with ASCII file
Need to be sensitive to constraints of NSC's
Need to indicate for each NSC:


   o Customer base
   o Scope of expertise


True cost is really too great - need to leverage what exists - pressures
regionals to handle more without compensation.

900 number for help?

Only real objection seems to be the requirement to accept all calls

                                   3






Higher Entity - when NSC's can't get closure, have a frustrated user.
But what power does it have?

Text of draft must be revised to recognize:


   o Limit scope and customers
   o Filter calls


Proposal:  NSC's must accept calls from other NSC's but can redirect
non-NSC's to other NSC's.

Format for transferring tickets between NSCs (email?).


   o TTS supposed to archive completed tickets, have current status
     (which NSC is holding which ticket)
   o Can be an archive of a mailing list
   o Authorized NSC's get read access


minimum:
To:    new-nsc
cc:    tts
Subj:  Ticket 3076

_______________
_______________
_______________

limitations of this minimum:  doesn't address who sees what, timers

Only archive (cc:) inter-NSC tickets?
Doesn't address local NOC support issues (what if problem never gets
to TTS?)



TSC's are supposed to:
Expedite tickets that aren't making progress, according to timers
arbitrate between NSC's act as user ombudsman

Do all the tickets get reported to TSC? No, not intra-NSC ones.
As an alternative, NSC's can do a monthly/weekly report on number of
tickets processed, resolved, etc.,


                                   4






How to clarify service requests:
JimoSheridan:TasomekminimalesettofrrequirementsoforuNSC:ble tickets.
   o Provide reporting on tt's.

Gene Hastings:  Rather than requirements, should produce guidelines (at
least for publicly-funded organizations) for reporting classes of
problems, monthly summaries, etc.

TSC -- keeps track of handoffs?

Some service centers have better ``clubs'' (i.e., leverage)

Classes of calls:



     general info who makes what can't get somewhere who's
     responsible for...  how address mail performance where is a
     resource unexpected routing is ?????  online losing packets
     protocol X doesn't work application level



Difference between complaint classification vs problem classification
(called in as one thing, but turned out to be another)

Sheridan:  can break down classes into 12 (?)  types (hardware,
software, connectivity, info, ....)

Reporting recommendations for NSC's - must incorporate into document.


   o Jim Sheridan, Gene Hastings, and Dan will draft.
   o Is this related to Statistics Working Group?
   o Should it be part of monthly report?
   o Working Group members will go to OPSTAT meeting and discuss.


To become an NSC, have to agree to rules (define customer base and scope
of expertise).


   o Accept calls from users in your base
   o Follow-up
   o Refer to other NSC (redirect)

                                   5






Should vendors be NSC?


   o Sheridan ``no''
   o O'Leary ``yes''


Can publish statistics and put pressure on vendors.

Action Plan


  1. Make changes to doc that were discussed.
  2. Make recommendation about NSC performance statistics.
  3. Maybe someone will implement?  write code or procedures?
  4. O'Leary will start?


Attendees

Vikas Aggarwal           [e-mail]
Kathy Atnip              [e-mail]
Eugene Hastings          [e-mail]
Steven Hunter            [e-mail]
Dale Johnson             [e-mail]
Dan Jordt                [e-mail]
Darren Kinley            [e-mail]
Tracy LaQuey Parker      [e-mail]
Mark Leon                [e-mail]
Daniel Long              [e-mail]
Lynn Monsanto            [e-mail]
Mark Moody               [e-mail]
Joel Replogle            [e-mail]
Ron Roberts              [e-mail]
Karen Roubicek           [e-mail]
Daisy Shen               [e-mail]
Jim Sheridan             [e-mail]
Dana Sitzler             [e-mail]
Mike Spengler            [e-mail]
Bernhard Stockman        [e-mail]
Joanie Thompson          [e-mail]



                                   6